home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20030409-20031118 / 000023_fdc@columbia.edu_Mon Apr 28 10:21:34 EDT 2003.msg < prev    next >
Text File  |  2020-01-01  |  5KB  |  97 lines
  1. Article: 14239 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.misc,comp.protocols.kermit.misc
  5. Subject: Re: Communication protocol for direct serial link (null-modem or similar)?
  6. Date: 28 Apr 2003 10:17:04 -0400
  7. Organization: Columbia University
  8. Lines: 80
  9. Message-ID: <b8jd50$4fr$1@watsol.cc.columbia.edu>
  10. References: <3R6qa.6946$b71.104830@news4.e.nsc.no> <b8bdvn$iun$1@watsol.cc.columbia.edu> <n05ra.7849$8g5.113401@news2.e.nsc.no>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1051539425 12588 128.59.39.139 (28 Apr 2003 14:17:05 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 28 Apr 2003 14:17:05 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.misc:9759 comp.protocols.kermit.misc:14239
  16.  
  17. In article <n05ra.7849$8g5.113401@news2.e.nsc.no>,
  18. Toralf Lund  <toralf-delete-this@procaptura.com> wrote:
  19. : On Fri, 25 Apr 2003 15:42:15 +0200, Frank da Cruz wrote:
  20. : > In article <3R6qa.6946$b71.104830@news4.e.nsc.no>, Toralf Lund
  21. : > <toralf-delete-this@procaptura.com> wrote:
  22. : > : I'm looking for a protocol that may be used for simple communication
  23. : > : across a direct serial link - RS232 using null-modem cable or similar
  24. : > : - between a Linux host and a simple (old) IPC (Intelligent Peripheral
  25. : > : Controller) board.
  26. : > : 
  27. : > : The IPC has no real OS, just a simple, custom kernel, and rather
  28. : > : limited development support, so the protocol needs to be simple to
  29. : > : implement. Also, the system is really low-end by today's standards -
  30. : > : it's has a 12.5Mhz MC68010 CPU and 1Mb RAM - so the runtime must be
  31. : > : fairly small and efficient.
  32. : > : 
  33. : > : The link will be used only to send simple packets ("commands") to the
  34. : > : IPC, and status from the IPC back to the Linux system; there will be
  35. : > : no file transfers or anything.
  36. : > : 
  37. : > : Protocols I've considered:
  38. : > : - Kermit
  39. : > : - AHDLC/LAPB (as utilised e.g. by PPP) - X/Y/Z-modem
  40. : > : 
  41. : > : What would you people out there recommend choosing? And does anyone
  42. : > : know of any good example source code that may help me get started? I'm
  43. : > : primarily interested in a nice and isolated implementation of the
  44. : > : packet communication itself, i.e. source code without all the
  45. : > : additional bits normally found in comms packages, like UI operations,
  46. : > : file I/O, modem dial etc., which I don't need (and I don't want them
  47. : > : there to confuse everything.)
  48. : > : 
  49. : > Embedded Kermit is exactly like that, except it's for transferring
  50. : > files, not sending simple messages:
  51. : > 
  52. : >   http://www.columbia.edu/kermit/ek.html
  53. : > 
  54. : > If you treat a message as a file, then Kermit would be fine.
  55. : How would I do that? What does the "file" interface look like?
  56. : 
  57. A file is whatever you want it to be.  From Kermit's point of view, it is
  58. an ordered series of bytes that has a name.  A message does not normally have
  59. a name, but otherwise it's the same as a file as far as Kermit is concerned.
  60.  
  61. When Kermit sends a file, it breaks it up into packets that have a certain
  62. maximum length.  Thus if the file is longer than a packet, multiple packets
  63. must be sent, and therefore packets must have sequence numbers.
  64.  
  65. Packets can be lost or damaged in transit; therefore they must have checksums
  66. or CRCs so errors can be detected.
  67.  
  68. Packets must be framed so the packet reader can identify the beginning and
  69. end as well as control fields such as the sequence number and checksum.
  70.  
  71. When errors are detected, the packet receiver must have a way of notifying
  72. the packet sender so the same packet can be retransmitted; thus packets are
  73. acknowledged or negatively acknowledged.
  74.  
  75. All this is necessary no matter whether you are sending a message or a file,
  76. and all of it is already done by Kermit.
  77.  
  78. The suitability of this model to the IPC (send command, get status back)
  79. depends on what you mean by "status".  If it's simply an indication of success
  80. or failure, this is handled within the Kermit protocol by the Acknowledgement
  81. to the Z (end-of-file) packet, which can contain a status indicator.
  82.  
  83. If the return status is something more complicated, it can be sent back as
  84. a file in the reverse direction.
  85.  
  86. You get a slight amount of extra overhead because Kermit is designed to send
  87. not just one file, but any number of them, in a single session.  Thus there
  88. is the per-session overhead (begin and end packet) and the per-file overhead
  89. ((begin packet, attribute packet, and end packet).  Then for each file, zero
  90. or more data packets.
  91.  
  92. So while this might not seem ideal for a simple command-and-status protocol,
  93. it's already done.  E-Kermit should be easily adaptable to the IPC, and
  94. Kermit software is already available for Windows, Unix, etc etc.
  95.  
  96. - Frank
  97.